Troubleshooting
This chapter helps you to isolate and solve problems with your unit. In the event this chapter does not provide a solution, or the solution does not solve your problem, check our support website at http://support.proxim.com.
Before you start troubleshooting, it is important that you have checked the details in the product documentation. For details about RADIUS, TFTP, terminal and telnet programs, and Web browsers, refer to their appropriate documentation.
In some cases, rebooting the unit clears the problem. If nothing else helps, consider a Soft Reset to Factory Default or a Forced Reload. The Forced Reload option requires you to download a new image file to the unit.
See the following:
Connectivity Issues
The issues described in this section relate to the connections of the unit.
Unit Does Not Boot
The unit shows no activity (the power LED is off).
Serial Link Does Not Work
The unit cannot be reached through the serial port.
- Check the cable connection between the unit and the computer.
- Ensure that the correct COM port is used.
- Start the terminal program; set the following connection properties (also see "HyperTerminal Connection Properties" in the Tsunami MP.11 Reference Manual), and then connect.
- Ensure that the unit and the computer use the same serial port configuration parameters.
- Disconnect and reconnect power to reset the unit. The terminal program displays Power On Self Tests (POST) messages and displays the following after approximately 90 seconds: Please enter password:
HyperTerminal Connection Problems
The serial connection properties can be found in HyperTerminal as follows:
- Start HyperTerminal and select Properties from the File menu.
- Select Direct to Com 1 in the Connect using: drop-down list (depending upon the COM port you use); then click Configure. A window such as the following is displayed:
- Enter or edit the information as follows, and click OK.
- Click the Settings tab and then click ASCII Setup.... A window similar to the following is displayed:
- Ensure that Send line ends with line feeds is selected and click OK twice. HyperTerminal is now correctly configured.
Ethernet Link Does Not Work
Cannot Use the Web Interface
- Open a command prompt window and enter ping <ip address unit> (for example ping 10.0.0.1). If the unit does not respond, make sure that you have the correct IP address.
If the unit responds, the Ethernet connection is working properly, continue with this procedure.- Ensure that you are using one of the following Web browsers:
- Ensure that you are not using a proxy server for the connection with your Web browser.
- Ensure that you have not exceeded the maximum number of Web Interface or CLI sessions.
- Double-check the physical network connections. Use a well-known unit to ensure the network connection is properly functioning.
- Perform network infrastructure troubleshooting (check switches, routers, and so on).
Communication Issues
Two Units Are Unable to Communicate Wirelessly
If a wireless link is possible after testing two units within close distance of each other, then there are two possible reasons why wireless connectivity is not possible while the MP.11 units are at their desired locations:
- There may be a problem in the RF path, for example, a bad connector attachment (this is the most common problem in installations) or a bad cable (water ingress).
NOTE: The cables can be swapped with known good ones as a temporary solution to verify cable quality.- Another reason may be related to an interference problem caused by a high signal level from another radio. This can be checked by changing the frequency and then verifying whether another channel works better or by changing the polarization as a way of avoiding the interfering signal. To know in advance how much interference is present in a given environment, a Spectrum Analyzer can be attached to a (temporary) antenna for measuring the signal levels on all available Channels.
NOTE: The antennas are usually not the problem, unless mounted upside down causing the drain hole to be quickly filled with radome.If a wireless link is not possible after testing two units within close distance of each other, then the problem is either hardware or configuration related, such as a wrong Network name, Encryption key, Network Secret or Base Station Name. To eliminate these issues from being a factor, resetting the both units to factory defaults is the recommended solution.
If a wireless link is not possible after resetting the units and verifying that one unit is a BSU with WORP Base interface configured and the other is a Satellite, then the problem is not configuration related and the only remaining reason is a possible hardware problem. Acquiring a third unit and then testing it amongst the existing units will help pinpoint the broken unit.
Setup and Configuration Issues
The following issues relate to setup and configuration problems.
Lost Password
If you lost your password, you must reset the unit to the default settings. See Hard Reset to Factory Default. The default password is public.
If you record your password, keep it in a safe place.
The Unit Responds Slowly
If the unit takes a long time to become available, it could mean that:
- No DHCP server is available.
- The IP address of the unit is already in use.
Verify that the IP address is assigned only to the unit. Do this by switching off the unit and then pinging the IP address. If there is a response to the ping, another device in the network is using the same IP address. If the unit uses a static IP address, switching to DHCP mode could remedy this problem. Also see Setting the IP Address with ScanTool.
- There is too much network traffic.
Web Interface Does Not Work
If you cannot connect to the unit Web server through the network:
- Connect a computer to the serial port of the unit and check the HTTP status. The HTTP status can restrict HTTP access at different interfaces. For more information, see "Serial Port" in the Tsunami MP.11 Reference Manual.
- Open a command prompt window and enter: ping <ip address unit> (for example ping 10.0.0.1)
- Ensure that you are using one of the following Web browsers:
- Ensure that you are not using a proxy server for the connection with your Web browser.
- Ensure that you have not exceeded the maximum number of Web Interface sessions.
Command Line Interface Does Not Work
If you cannot connect to the unit through the network:
- Connect a computer to the serial port of the unit and check the SNMP table. The SNMP table can restrict telnet or HTTP access. For more information, see "Serial Port" in the Tsunami MP.11 Reference Manual.
- Open a command prompt window and enter: ping <ip address unit> (for example ping 10.0.0.1).
- Ensure that you have not exceeded the maximum number of CLI sessions.
TFTP Server Does Not Work
With TFTP, you can transfer files to and from the unit. Also see TFTP Server Setup. If a TFTP server is not properly configured and running, you cannot upload and download files. The TFTP server:
If the TFTP server does not upload or download files, it could mean:
Online Help Is Not Available
Online help is not available:
- Make sure that the Help files are installed on your computer or server. Also see Step 9: Install Documentation and Software.
- Verify whether the path of the help files in the Web Interface refers to the correct directory. See Set the Help Link Location.
Changes Do Not Take Effect
Changes made in the Web Interface do not take effect:
Wait until the reboot is completed before accessing the unit again.
VLAN Operation Issues
The correct VLAN configuration can be verified by "pinging" wired hosts from both sides of the device and the network switch. Traffic can be "sniffed" on the wired (Ethernet) network. Packets generated by hosts and viewed on one of the backbones should contain IEEE 802.1Q compliant VLAN headers when in Transparent mode. The VLAN ID in the headers should correspond to one of the VLAN Management IDs configured for the unit in Trunk mode.
The correct VLAN assignment can be verified by pinging:
Ultimately, traffic can be "sniffed" on the Ethernet interface using third-party packages. Most problems can be avoided by ensuring that 802.1Q compliant VLAN tags containing the proper VLAN ID have been inserted in the bridged frames. The VLAN ID in the header should correspond to the assigned VLAN.
What if network traffic is being directed to a nonexistent host?
Link Problems
While wireless networking emerges more and more, the number of wireless connections to networks grows every day. The Tsunami MP.11 unit is one of the successful product families used by customers today who enjoy the day after day high-speed, cost-effective connections. To successfully use the connections, technicians must be able to troubleshoot the system effectively. This section gives hints on how a unit network could be analyzed in the case of "no link," a situation in which the customer thinks that the link is down because there is no traffic being passed.
The four general reasons that a wireless link may not work are related to:
You have tested the equipment in the office and have verified that the hardware and configurations are sound. The path calculation has been reviewed, and the path has been double-checked for obstacles and canceling reflections. Still, the user reports that the link does not work.
Most likely, the problem reported is caused by the environment or by improper tests to verify the connection. This article assumes that the test method, cabling, antennas, and antenna alignment have been checked. Always do this before checking the environment.
General Check
Two general checks are recommended before taking any action:
Statistics Check
Interference and other negative environment factors always have an impact on the number of correctly received frames. The Tsunami MP.11 models give detailed information about transmission errors in the Web interface, under Monitor.
The windows that are important for validating the health of the link are:
- Monitor / Wireless / General (Lowest level of the wireless network): Check FCS errors: Rising FCS errors indicate interference or low fade margin. So does Failed count. If only one of those is high, this indicates that a source of interference is significant near one end of the link.
- Monitor / Interfaces / Wireless (One level higher than Wireless / General): The information is given after the wireless Ethernet frame is converted into a normal Ethernet frame. The parameters shown are part of the MIB-II.
- Both operational and admin status should be up. An admin status of down indicates that the interface is configured to be down.
- In Discards and Out Discards indicate overload of the buffers, likely caused by network traffic, which is too heavy.
- In Errors and Out Errors should never happen; however, it might happen if a frame's FCS was correct while the content was still invalid.
- Monitor / Wireless / WORP (Statistics on WORP): WORP runs on top of normal Ethernet, which means that the WORP frame is in fact the data field of the Ethernet frame. Send Failure or Send Retries must be low in comparison to Send Success. Low is about 1%. The same applies for Receive Success versus Receive Retries and Receive Failures. Note that the Receive Failures and Retries can be inaccurate. A frame from the remote site might have been transmitted without even being received; therefore, the count of that frame might not have been added to the statistics and the receiver simply could not know that there was a frame.
- Remote Partners indicates how many SUs are connected (in case of a BSU) or whether a Base is connected (in case of a Subscriber).
- Base Announces should increase continuously.
- Registration Requests and Authentication Requests should be divisible by 3. WORP is designed in a way that each registration sequence starts with 3 identical requests. It is not a problem if, once in a while, one of those requests is missing. Missing requests frequently is to be avoided.
- Monitor / Per Station (Information per connected remote partner): Check that the received signal level (RSL) is the same on both sides; this should be the case if output power is the same. Two different RSLs indicate a broken transmitter or receiver. A significant difference between Local Noise and Remote Noise could indicate a source of interference near the site with the highest noise. Normally, noise is about -80 dBm at 36 Mbps. This number can vary from situation to situation, of course, also in a healthy environment.
- Monitor / Link Test (Information used by Administrators for on-the-spot checking): Check the received signal level (RSL) and noise level. Compare the RSL with the values from path analysis. If the figures differ significantly from the values recorded at the Per Station window, check for environment conditions that change over time.
Analyzing the Spectrum
The ultimate way to discover whether there is a source of interference is to use a spectrum analyzer. Usually, the antenna is connected to the analyzer when measuring. By turning the antenna 360 degrees, one can check from which direction the interference is coming. The analyzer will also display the frequencies and the level of signal is detected.
Proxim recommends performing the test at various locations to find the most ideal location for the equipment.
Avoiding Interference
When a source of interference is identified and when the level and frequencies are known, the next step is to avoid the interference. Some of the following actions can be tried:
- Changing the channel to a frequency away from the interference is the first step in avoiding interference. For countries that require DFS, it might be not possible to manually select a different frequency.
- Each antenna has a polarization; try to change to a polarization different from the interferer.
- A small beam antenna looks only in one particular direction. Because of the higher gain of such an antenna, lowering the output power or adding extra attenuation might be required to stay legal. This solution cannot help when the source of interference is right behind the remote site.
- Lowering the antennas can help avoid seeing interference from far away.
Move the antennas to a different location on the premises. This causes the devices to look from a different angle, causing a different pattern in the reception of the signals. Use obstructions such as buildings, when possible, to shield from the interference.
Conclusion
A spectrum analyzer can be a great help to identify whether interference might be causing link problems on Tsunami MP.11 systems.
Before checking for interference, the link should be verified by testing in an isolated environment, to make sure that hardware works and your configurations are correct. The path analysis, cabling and antennas should be checked as well.
Statistics in the web interface under Monitor tell if there is a link, if the link is healthy, and a continuous test can be done using the Link Test.
|